/ Appl. No. 09/591,035 £ 
Amdt. dated November 12^003 
Reply to Office Action of August 12, 2003 

Remarks/Arguments 

Claims 1, 3, 5, 6, 9, 11, 13, 14, and 17 have been amended. No new claims have been 
added. No claims have been canceled. Claims 1-24 remain pending in this application. 
Reexamination and reconsideration of the application as amended are respectfully requested. 

Claim Rejections - 35 USC § 103(a) 

The Examiner rejected claims 1-24 under 35 U.S.C. § 103(a) as being unpatentable over 
Helgeson et al (U.S. 2002/0073236), and in view of O'Brien et al (U.S. 6,351,776). Assignee 
respectfully traverses this rejection for the reasons set forth below. 

By use of the present invention, a transaction-based application is adapted to process 
transactions over a network such as an internet or intranet. The transaction-based application is 
adapted by scanning the source code of the transaction-based application to identify a transaction 
and information related to the transaction; storing the related information in a database; 
extracting from the database parameter definitions describing communication of information by 
the transaction; identifying a parameter usage type for each parameter, said parameter usage type 
selectable from the parameter usage type set comprising input, output, input/output, and 
unreferenced; displaying the transaction and a subset of the related and extracted information; 
allowing a user to select the transaction; and using the identified and extracted information to 
package the user-selected transaction in a form compatible with a connector building tool. 
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Thus, the present invention is directed towards analyzing a transaction-based application 
in order to build a connector to adapt the transaction-based application to process transactions 
over a network such as an internet or intranet. Although Helgeson et al. teaches the use of a 
connector by an application to process transactions over a network, Helgeson et al. fails to 
provide any teachings as to how the application may be analyzed to build such a connector. 

In particular, the Examiner asserts that Helgeson et al. at p. 2, col 0016 teaches a method 
of adapting a transaction-based application to process transactions over a network, said 
transaction-based application comprising source code describing a transaction and information 
related to the transaction, hereinafter related information, said method comprising the steps of 
scanning the source code of the transaction-based application to identify the transaction and the 
related information. However, at p. 2, col. 0016, Helgeson et al. teaches: 

"The system may also include a monitor component for monitoring changes of a data 
object at a system, with the monitoring component having both a system independent 
service subcomponent and a system specific service component utilizing a native API of 
the monitored system to monitor changes of the data object. The system may also include 
a mapper component for identifying a local object identifier and a document type." 
' Helgeson et al. does not teach scanning application source code for a transaction or any type of 
scanning of application source code. Helgeson et al. at p. 2, col. 0016 teaches the monitoring of 
application data. The monitoring of application data does not scan the application source code to 
identify a transaction. Thus, Helgeson et al. fails to teach or suggest the first element of 
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independent claims 1, 9, and 17, and even if one were to combine the teachings of Helgeson et 
al and O'Brien et al, the combination still fails to teach or suggest the present invention. 
Assignee therefore respectfully requests that the Examiner reconsider and withdraw the 35 
U.S.C. § 103(a) rejections of independent claims 1, 9, and 17. 

The Examiner also asserts that Helgeson et al at p. 12, col 0277-0278 teaches storing the 
related information in a database; extracting from the database parameter definitions describing 
communication of information by the transaction; and identifying a parameter usage type for 
each parameter, said parameter usage type selectable from the parameter usage type set 
comprising input, output, input/output, and unreferenced. However, at p. 12, col 0277-0278, 
Helgeson et al teaches: 

In the presently preferred embodiment, the method invocation currently only supports 

invocation of database stored procedures although in alternative embodiments this will be 

extended to other types of persistence mechanisms. 

These stored procedures provide the actual intelligence of taking the marshaled 

arguments that come in, and storing them in specific fields in the database, and vice 

versa. Thus a combination of the meta-data store and the stored procedures create an 

abstraction layer that allows the base SabaObject to store all objects through a simple, 

uniform algorithm." 

If, as discussed above, Helgeson et al failsj0^each scanning application source code to identify 
a transaction and related information related to the transaction, then Helgeson et al also fails to 
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teach storing the related information identified in the scan of the source code. Helgeson et al. 's 
teachings of using a relational database and stored procedure calls to store and manipulate 
attributes of business objects in a uniform manner do not teach or suggest storing related 
information identified in a scan for a transaction in source code. 

Similarly, although Helgeson et al. 's teachings of using a relational database and stored 
procedure calls to store and manipulate attributes of business objects in a uniform manner teach 
extracting business object attributes from the relational database, Helgeson et al.y^o teach or 
suggest extracting from the database parameter definitions describing communication of 
information by the transaction; and identifying a parameter usage type for each parameter, said 
parameter usage type selectable from the parameter usage type set comprising input, output, 
input/output, and unreferenced. Thus, Helgeson et al. fails to teach or suggest the second, third, 
and fourth elements of independent claims 1, 9, and 17, and even if one were to combine the 
teachings of Helgeson et al. and O'Brien et al., the combination still fails to teach or suggest the 
present invention. Assignee therefore respectfully requests that the Examiner reconsider and 
withdraw the 35 U.S.C. § 103(a) rejections of independent claims 1, 9, and 17. 

The Examiner also asserts that Helgeson et al. at p. 19, para. 0387 teaches displaying the 
transaction and a subset of the related and extracted information: 

"For transactions, an application developer has two options: 1) to explicitly demarcate the 
boundaries of a transaction, or 2) to use declarative transactional management available 
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with EJBs. Use of declarative transactional management is cleaner and is strongly 
recommended. In this case, the level of granularity for managing transactions corresponds 
to methods in a bean. Instead of interleaving transaction boundaries within business logic, 
transactional attributes are separately declared in the bean's deployment descriptor (for a 
specific method, or as the bean's default) as one of the following six options: 
TX_NOT_SUPPORTED, TX_SUPPORTS, TXJREQUIRED, TX_REQUIRES_NEW, 
TX_MANDATORY, TX_BEAN_MANAGED. Details of these can be found in books on 
EJB." 

Similar to Assignee's above response relative to the second element of claims 1, 9, and 17, if 
Helgeson et al fails to teach scanning application source code to identify a transaction and 
related information related to the transaction, then Helgeson et al also fails/o teach displaying a 
subset of the related information identified in the scan of the source code. 



The Examiner also asserts that O'Brien etal at col. 15, In. 21-27 teaches using the 
identified and extracted information to package the user-selected transaction in a form 
compatible with a connector building tool: 

"If at step 714 the user must be sent back to the same database, query is made at step 740 
to determine if that database is still up. If it is, the request is passed to the pool 
specification 720 where it is subsequently passed to the database object 236, on to the 
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connection pool 730, and the appropriate database, either the transaction database 150 or 

the query database 152." 
A "connection pool" is not a connector building tool, and O'Brien et al. teaches at col. 8, In. 16- 
18 "The EJB cluster (EJBC) caches memory of common resources such as the pooling of data 
connections and the like, as well as data objects." Similar to Assignee's above response relative 
to the second element of claims 1, 9, and 17, if the combination of Helgeson etal. and O'Brien et 
al. failsJ;o teach scanning application source code to identify a transaction and related 
information related to the transaction, then the combination of Helgeson et al. and O'Brien et al 
also fails to teach using the related information identified in the scan of the source code. Thus, 
O'Brien et al. fails to teach or suggest the seventh element of independent claims 1, 9, and 17, 
and even if one were to combine the teachings of Helgeson et al. and O'Brien et al, the 
combination still fails to teach or suggest the present invention. Assignee therefore respectfully 
requests that the Examiner reconsider and withdraw the 35 U.S.C. § 103(a) rejections of 
independent claims 1, 9, and 17. 



Relative to dependent claims 2-8, 10-16, and 18-24, these dependent claims depend from 
independent claims 1, 9, and 17, respectively. Since these dependent claims depend from 
independent claims 1, 9, and 17, and Assignee believes it has successfully traversed the 
Examiner's rejection of independent claims 1, 9, and 17, Assignee respectfully requests that the 
Examiner reconsider and withdraw the rejections of dependent claims 2-8, 10-16, and 18-24. 
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Conclusion 

Assignee therefore respectfully requests that the Examiner reconsider all currently 
outstanding objections and rejections and that they be withdrawn. It is believed that a full and 
complete response has been made to the outstanding Office Action and, as such, the present 
application is in condition for allowance. If the Examiner believes, for any reason, that personal 
communication will expedite prosecution of this Application, the Examiner is invited to 
telephone the undersigned at the number provided. Prompt and favorable consideration of this 
Response is respectfully requested. 

Respectfully submitted, 




Prentiss Wayne Johnson, RegxNo. 
Attorney for IBM Corporation, and authorized to act on behalf of 
IBM Corporation, the assignee of the entire right, title, and interest 
in the Application 

IBM Corporation, Intellectual Property Law 
555 Bailey Avenue, J46/G467 
San Jose, CA 95141-9989 
Telephone: (408) 463-5673 



Date: November 12, 2003 
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